docs: note unpublished-port filter vs pre-netfilter DNAT - #25760
Merged
Conversation
Explain that DOCKER-USER cannot re-open unpublished container ports when another datapath already rewrites packets to those addresses. Signed-off-by: Dean Chen <862469039@qq.com>
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
github-actions
Bot
added
area/engine
Signed-off-by: Dean Chen <862469039@qq.com>
Contributor
Author
|
vale didn't like "datapath" — split it to "data path". |
robmry
reviewed
Aug 12, 2026
Contributor
There was a problem hiding this comment.
Thank you @locker95, I agree it's worth a note here.
But for most readers, we'll probably need to say what "direct routing" is. With the CNI example, it sounds quite complicated at the moment. It'd probably also be better to link to the section on how to use the gateway_mode options, unfortunately they're not easy to guess.
How about something like ...
> [!NOTE]
>
> By default, remote hosts can only reach a container through a port published
> to one of the Docker host's addresses. Sending packets to the container's own
> IP address instead ("direct routed" access) is not allowed.
>
> These packets are dropped by a rule in the `raw` table's `PREROUTING` chain,
> which is processed before the `filter` table. So, they never reach the
> `DOCKER-USER` chain, and a rule in `DOCKER-USER` cannot allow them.
>
> Any packet that reaches the host's firewall rules already addressed to a
> container is treated this way. For example, a Kubernetes CNI plugin may
> translate a Service address to a container address before the packet reaches
> the host's `PREROUTING` rules. Docker cannot distinguish the result from a
> packet routed to the container by a remote host. Which host interface these
> packets arrive on depends on the plugin's data path — for an overlay network
> it is normally the tunnel device.
>
> To allow direct routed access to a container's *published* ports, use network
> option `com.docker.network.bridge.trusted_host_interfaces`, or daemon option
> `allow-direct-routing`. Unpublished ports are still protected. See
> [Direct routing to containers in bridge networks](./port-publishing.md#direct-routing-to-containers-in-bridge-networks).
> To allow direct routed access to all container ports, published or not, see
> [Gateway modes](./port-publishing.md#gateway-modes).
And, something similar for nftables (firewall-nftables.md, end of "Migrating ACCEPT rules") ...
> [!NOTE]
>
> By default, remote hosts can only reach a container through a port published
> to one of the Docker host's addresses. Sending packets to the container's own
> IP address instead ("direct routed" access) is not allowed.
>
> These packets are dropped by a rule in the `raw-PREROUTING` chain of the
> `docker-bridges` tables. Because a drop is final, a rule in one of your own
> tables cannot allow them. And, because that chain runs at the `prerouting`
> hook, before Docker's `filter-FORWARD` rules, a firewall mark added with
> `--bridge-accept-fwmark` has no effect on it.
>
> Any packet that reaches the host's firewall rules already addressed to a
> container is treated this way. For example, a Kubernetes CNI plugin may
> translate a Service address to a container address before the packet reaches
> the host's prerouting rules. Docker cannot distinguish the result from a
> packet routed to the container by a remote host. Which host interface these
> packets arrive on depends on the plugin's data path — for an overlay network
> it is normally the tunnel device.
>
> To allow direct routed access to a container's *published* ports, use network
> option `com.docker.network.bridge.trusted_host_interfaces`, or daemon option
> `allow-direct-routing`. Unpublished ports are still protected. See
> [Direct routing to containers in bridge networks](./port-publishing.md#direct-routing-to-containers-in-bridge-networks).
> To allow direct routed access to all container ports, published or not, see
> [Gateway modes](./port-publishing.md#gateway-modes).
Rewrite the note in plain language (what direct routing is, why raw PREROUTING wins over DOCKER-USER) and mirror it for nftables. Point at trusted_host_interfaces / allow-direct-routing and the gateway_mode docs. Signed-off-by: Dean Chen <862469039@qq.com>
Contributor
Author
|
good call — rewrote the note along those lines and added the matching one on the nftables page (raw-PREROUTING / fwmark won't help). linked the direct-routing + gateway_mode sections too. |
Signed-off-by: Dean Chen <862469039@qq.com>
dvdksn
approved these changes
Aug 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When something else (e.g. a CNI) rewrites packets to a container IP before host netfilter, Docker's unpublished-port protection still applies.
DOCKER-USERnever sees that as "published" traffic.Added a short note under the iptables DOCKER-USER section pointing at port publishing /
nat-unprotected.Fixes #25676